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Beschreibung 

[0001 ] Die vorliegende Erfindung betrifft ein Verfahren zur Uberprufung der Verfugbarkeit eines Servers, ein Steue- 
rungsprogramm und elnen Client fur ein verblndungslose Oienste bereitsteliendes Netz, 

s [0002] Eine zuverlassige Uberprufung der Verfugbarkelt eines Servers ist Insbesondere bei lose gekoppelten Client- 
Server-Beziehungen in paketorientierten Datermetzen von groBer Bedeutung. Erkenni ein Client fruhzeitig, daB ein 
Serverijberiastetoderausgefallen ist,sokdnnen noon rechtzeitigGegenmaBnahmen elngeleitet warden, beispielsweise 
Suche nach einem Aiternatlv-Server oder Erzeugen von Warnhlnwelsen. Verfahren zur Uberprufung der Verfugbarkelt 
eines Servers, zu denen auch im H.323-Standard. Stand 11/2000, Kap. 7.2.2 beschrlebene Keep-A!ive-Tests zahlen, 

10 werden angewendet, wenn keine permanente Kommunikationsbeziehung zwischen Client und Server besteht, ein feh- 
lerfreies Bestehen einer soichen Beziehung jedoch Grundlage fur eine gewiinschte Funktionalltat ist, beispielsweise 
Internet-Telephonie. In paketorientierten Netzen dienen Keep-Alive-Tests beispielsweise dazu, Kommunikationsteilneh- 
mem einen quasi leltungsvermittelnden Charakter hinsichtlich gegenseitiger Erreichbarkeit zu slmuileren. 
[0003] Bei gangigen Keep-Alive-Tests sendet ein Client in zyklischen Zeitabstanden Verfijgbarkeltsanfragen an einen 

'5 ausgewahlten Server. Wird eine Verfugbarke'itsanfrage duroh den Server innerhalb eines vorgebbaren Zeitraums be- 
antwortet, gilt der Server als verfugbar und die Kommunikationsbeziehung daher als aktiv. Nachteilig an dieser Vorge- 
hensweise ist, daB der Server in der Regel durch eine Beantwortung samtlicher Client-Anfragen erheblich belastet wird. 
[0004] Dervorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zur Uberprufung der Verfugbarkelt 
eines Servers, das eine Minimierung der Belastung des Sewers durch an inn gerichtete Verfugbarkeitsanfragen ermog- 

so lioht, sowie zur Durchfuhrung des Verfahrens geeignete technlsche Implementierungen anzugeben. 

[0005] Diese Aufgabe wird erfindungsgemaB durch ein Verfahren mit den in Anspruch 1 , ein Steuemngsprogramm 
mit den In Anspruch 7 und elnen Client mit den in Anspruch 8 angegebenen Merkmalen gelost. VDrteilhafte Weiterbi!- 
dungen der vorliegenden Erfindung sind in den abhiingigen Anspriichen angegeben. 

[0006] Ein wesentlicher Aspekt der vorliegenden Erfindung besteht darin, daB ein Client, der auf eine an einen Server 
gerichtete VerfCigbarkeitsanfrage eine Bestatigungsmeldung vom Server empfangen hat, eine Meldung uber die Ver- 
fugbarkeit des Servers an weitere Clients ubermiftelt. Daraufhin unterbinden die vorgebbaren weiteren Clients zumindest 
fur ein vorgebbares Zellintervall ein Ubermittein einer VerfQgbarkeltsanfrage an den Server. Auf diese Weise kann die 
Belastung des Servers durch Verfugbarkeitsanfragen erheblich reduzi&rt werden, ohne daB dies beispielsweise zu 
Lasten einer nioht mehr rechtzeitigen Erkennung eines Serverausfalls oder einer Serveruberlastung geht. 
so [0007] Das Dokument US-2001/054158 wird als nachstligender Stand der Technlk angesehen, und offenbart ein 
Verfahren zur Uberprufung dor Verfugbarkeit eines Servers, 

[0008] Die vorliegende Erfindung wird nachfolgend an einem AusfQhrungsbeispiel anhand der Zeichnung nSher er- 
lautert. Es zeigt 

as Figur 1 ein Anwendungsumfeld der vorliegenden Erfindung mit zahlreichen Clients und Servern in einem paketori- 
entierten Netz mit mehreren Tellnetzen, 

Figur 2 ein Ablaufdiagramm fur ein Verfahren zur Uberprufung der Verfugbarkeit eines Servers, 

i° Figur 3 ein Ablaufdiagramm fur ein gegenuber Figur 2 modifiziertes Verfahren, bei dem zusalzlich die Verfugbarkeit 
von Clients durch den Server iiberpruft wird. 

[0009] in Figur 1 ist ein Kommunikatlonssystem dargestellt, das ein paketorientiertes Netz mit mehreren Teiinetzen 
101, 110, 120, 130, Server 102 bis 104 und mehrere Clients 1 1 1 bis 115, 121 bis 123, 131 bis 133 umfaBt. Die Clients 
45 m bis 11 5, 121 bis 123, 131 bis 1 33 nutzen von den Servern 102 bis 1 04 angeboteneDienste, beispielsweise Internet- 
Telefonie. 

[0010] Bei den Teiinetzen 110, 120, 130 handelt es sich urn iokale Subnetze, die jeweils Qber einen Gatekeeper 
verfugen. Die Gatekeeper dienen vornehmiich zur Zugangskontrolle und zu AdreBiiberselzungsdiensten. Diese Funk- 
tionalitat der Gatekeeper kann durch Server im paketorientierten Netz iibernommen werden. 
so [0011] Zur Nutzung von durch einen Server 102 bis 104angebotenen Diensten registrieren sich die Clients 111 bis 
115, 121 bis 123, 131 bis 133 zunfichst. am jeweiligen Server. Dabel wird ein Zeltraum spezlflzlert, innerhalb dessen 
eine Registrierung als giiltig behandelt wird. Der Ablauf eines Registrierungsverfahrens wird exemplarisch und ohne 
Beschrankung der Allgemeingultigkeitfurden Client 111 dargestellt. 

[0012] Der Client 1 1 1 verfugtuberelnezentraie ProzessorelnheltfCPU), einen Arbeitsspeicher(RAM), oine Festplatte 
55 zurnichtfluchtigen Speicherung von Daten (HD), einen Netzwerkadapter(Tx/Rx) undeine Zeltsteuerungseinheit (Timer). 
Elnen soichen Aufbau und eine solche Funktionalltat konnen auch die Dbrigen in Figur 1 dargesteilten Clients 112 bis 
115, 121 bis 123, 131 bis 133 aufweisen. 

[0013] Zur Registrierung an einem der Server 1 02 bis 104 (Ibermittelt der Client 1 1 1 eine Meldung mit einer Registrle- 
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rungsanforderung RRQ an einen Server, der einen gewdnschten Dienst bersitstelit. In der Meldung mit der Registrte- 
rungsanforderung RRQ wird eiti Zeitraum speziflzlert, innerhalb dessen die Registrlerung des Clients 1 11 am ausge- 
wahlten Server gtlltig seln soli. AuGerhalb dieses Zeitraums gilt die Registrtemng des Clients als ungultig. 
[0014] Bei Verfugbarkeit antwortet der ausgewahlte Server durch eine Meldung mit Registrierungsbestatigung RCF 
auf die Registrierungsanfrage. In derMeldung mitderRegistrierungsbestatigung RCFebenfalis einen GQItigkeitszeitraum 
fOr die Registrlerung spezifiziert. Der vom ausgewahlten Server bestatigte Gultigkeitszeitraum entspricht entweder dem 
vom Client 1 1 1 angegebenen Zeitraum oder 1st ktirzer als dieser. 

[0015] Innerhalb des GQItigkeitszeitraums fur die Registrierung kann der Client 1 1 1 Verfugbarkeitsanfragen an den 
ausgewahlten Server richten. Derartige Verfugbarkeitsanfragen, die auch als Keep-Alive-Tests bezeichnet werden, 
werden ebenfalls in Form einer Meldung mit einer Registrierungsanfrage RRQ an den ausgewahlten Server ubermittelt, 
Eine im Rahmen eines Keep-Alive-Tests ubermittelte Meldung mit Registrierungsanfrage RRQ weist gegenuber ge- 
wShnlichen Meldungen mit Registrierungsanfrage eln gesetztes Keep-Alive-Bit ist. 

[0016] Entsprechend den ITU-T-Empfehlungen H.225.0, Stand 1 1/2000, Kapitel 7.9 ist eine verkurzte Meldung mit 
Registrierungsanfrage fur eine "Lightweight Registration" bereits ausreichend. Dabei weist die Meldung mit Registrie- 
rungsanfrage iediglich Angaben iiber eine Reglstrierungs- und Status-Transportadresse (RAS-Adresse) des Clients, 
ein gesetztes Keep-Alive-Bit, einen Endpunktidentifikator fur den Client, einen Server- bzw. Satekeepertdentiflkator, 
Berecfitigungsmarken (Tokens) fiir auszufQhrende Operationen und einen Guitigkeitszeitraum fur die Registrierung. 
[0017] Eine Meldung mit Registrierungsanforderung RRQ, die im Rahmen eines Keep-Alive-Tests an den ausgewahl- 
ten Server ubermittelt wird, kann auch zur Verlangerung des Gultigkeitszeitraums der Registrierung verwendet werden. 
Dies gilt jedoch nur dann, wenn die Meldung noch Innerhalb des GQItigkeitszeitraums der Registrierung vom ausge- 
wahlten Server empfangen wird. Daher soliten zur Ermittlung des Endes eines Gultigkeitszeitraums durch einen Client 
auch Meldungs- und Bearbeitungsverzogerungen berucksichtigt werden. Nach dem Ende des Gultigkeitszeitraums der 
Registrierung istzurerneuten Registrierung eine Ubermittlung einer oben beschrlebenen verkUrzten Meldung mit Re- 
gistrierungsanfrage nicht mehr ausreichend. 

[0018] Falls die Meldung mit der Registrierungsbestatigung RCF keine Angabe iiber einen Gultigkeitszeitraum der 
Registrierung aufweist, wird dies dahingehend gewertet werden, daB der ausgewahlte Server keine Keep-Alive-Mecha- 
nlsmen fur Verfugbarkeitsanfragen unterstiitzt, Clients soliten bei Empfang einer solchen Meldung ohne Angabe iiber 
einen Gultigkeitszeitraum ein Versenden von Verfugbarkeitsanfragen an den jewelligen Server unterblnden. 
[0019] Nach Ablauf der Gultigkeit einer Registrlerung kann der ausgewahlte Server eine Meldung mit sinem entspre- 
ohenden Hlnweis an den betroffenen Client Qbermitteln, urn diesen Oberden Ablauf des Guitigkeitszeitraums zu infor- 
mleren. Dies ist insbesondere bei einem Verlust der Synchronisierung zwischen Zeitsteuerungseinheiten am Client 
einerselts und am Seiver andererselts von Vorteii. 

[0020] Sendet der Client 111 nach dem Ende des Gultigkeitszeitraums der Registrierung eine oben bcsciiriobon 
verkOrzte Meidung mit Registrierungsanfrage RRQ und gesetztem Keep-Alive-Bit an den ausgewahlten Server, so wird 
der Server durch eine Meidung mit RegistrierungszurOckweisung RRJ reagieren. In einer solchen Meidung kann auch 
ein Zuriickweisungsgrund angegeben seln. 

[0021] Urn eine unnotige Belastung eines Servers 102 bis 1 04 durch Verfugbarkeitsanfragen von Clients 1 1 1 bis 1 1 5, 
121 bis 123, 131 bis 133 zu vermeiden, informiert ein Client, der eine positive oder eine negative Antwort auf eine 
Verfiigbarkeitsanfrage erhaiten hat, mittels einer Multicast-Meldung MCM samtliche Clients innerhalb desselben Teil- 
netzes 110, 120, 130 iiber die Verfugbarkeit des jeweiligen Servers. Durch eine Begrenzung auf dasselbe Teilnetz 
ko'nnen aufSerdem Probleme im Hinbllck auf nicht allgemeln auflosbare Adressen umgangen werden. Insbesondere 
wird eine unnotige Netzbelastung durch nichtadressierbare Meldungen verhindert. 

[0022] Das in Figur 2 dargestellte Ablaufdiagramm dlent zur weiteren Veranschaullchung eines Verfahrens zur Uber- 
prufung der Verfugbarkeit eines Servers in einem paketorientierten Kommunikationsnetz. Ausgangspunkt des Verfah- 
rens ist ein Start eines Timers bzw. eines Zahters einer Zeitsteuerungsainheit eines Clients (Schritt 201). Durch den 
Timer werden Zeitpunkte festgeiegt, zu denen VerfQgbarkeitsanfragen des Clients an einen ausgewahlten Server Uber- 
mittelt werden solien. 

[0023] Nach dem Start des Timers uberwacht der Client den Empfang von Muiticast-Meldungen MCM, aus denen 
sich Aussagen iiber die Verfugbarkeit eines Servers ergeben (Schritt 202). Empfangt der Client eine solche Multicast- 
Meldung, so wird der Timer zuruckgesetzt( Schritt 208). Dadurch wird eine Obermittlung von VerfQgbarkeitsanfragen an 
den ausgewahlten Server fQr ein vorgebbares Zeitintervall unterbunden. 

[0024] Sofern keine neue Multicast-Meldung empfangen wurde, wird zusatzlich Oberpruft, ob der Timer abgelaufen 
und damit ein Zeifpunkt zum Absetzen einer neuen Verfiigbarkeitsanfrage erreicht ist (Schritt 203), Wenn der Timer 
noch nicht abgelaufen Ist, werden weitsrhin der Empfang von Muiticast-Meldungen und der Ablauf des Timers uberpruft. 
Ist der Timer abgelaufen, wird eine Verfugbarkeitsanfrage an den ausgewahlten Server versendet (Schritt 204), 
[0025] In Schritt 205 wird zumindest impllzit die Verfugbarkeit oder Nichtverfugbarkeit des ausgewahlten Servers 
festgestellt ist der ausgewahlte Server verfilgbar, so antwortet dieser durch eine an den anfragenden Client gerichtete 
Bestatigungsmeidung auf die VerfQgbarkeitsanfrage (Schritt 206). Nach Erhalt der Bestatigungsmeidung informiert der 
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anfragende Client samtliche weiteren Clients innerhalb desseiben Teiinetzes fiber die Verfiigbarkeit des ausgewahlten 
Servers mittels einer Multioast-Meidung (Schritt 207). Daraufhin unterbinden die weiteren Clients, welche die Multicast- 
Meldung empfangen haben, ihrerssits sin Obermitteln von Verfiigbarkeitsanfragen an den ausgewahlten Server fOr em 
vorgegebenes Zeitintervall, 

[0026] Da bei Ausfall oder Uberiastung des ausgewahjten Servers keine Bestatigungsmeidung uber dessen Verfiig- 
barkeit versendet wird, wird iiberprfift, ob der ausgewahlie Server zumindest in der Lage 1st, mit einer Nichtverfugbar- 
keitsmeldung auf die Verfugbarkeitsanfrage zu reagieren (Schritt 209). Bei einer Gberiastung des ausgewahlten Servers 
ware dies belspielsweise nooh moglich. Dagegen ist bei einem Ausfall des ausgewahlten Servers nicht mehr mit einem 
Versenden einer NichtverfijgbarkeHsmeldung zu rechnen. Daher wird uberpruft ob ein Zeitllmit fGr den Empfang einer 
Bestatigungsmeidung oder einer Nichtverfiigbarkeitsmeldung erreicht wird (Schritt 211). Wird dieses Zeitiimit uberschrit- 
ten, so Qbermittelt der anfragende Ctlent eine Multlcast-Meidung fiber die Nichtverfugbarkeit des ausgewahlten Servers 
an samtliche Clients innerhalb desseiben Teiinetzes (Schritt 210). In entsprechender Weise wird verfahren, wenn dar 
anfragende Client innerhalb des fur eine Anwort auf die Verfugbarkeitsanfrage zulassigen Zeitlimits elne Nichtverfiig- 
barkeitsmeldung erhait. 

[0027] Das beschrsebene Verfahren zur Uberprufung der Verfiigbarkeit eines Servers wird vorzugsweise durch ein 
Steuerungsprogramm implementlert, das in einen Arbeltsspeicher eines Clients ladbar ist und zumindest einen Cotfe- 
Abschnltt aufweist, bei dessen Ausfuhrung die vorangehend beschriebenen Schritte Obermitteln der VerfDgbarkeitsan- 
frage, Oberwachen des Empfangs einer Bestatigungsmeidung, Obermitteln einer Meldung fiber die Verfiigbarkeit an 
weitere Clients, Oberwachen des Empfangs von Meldungen weiterer Clients und ggf. Unterbinden cfes Versendens von 
Verfiigbarkeitsanfragen ablaufen. Mittels des Steuerungsprogramms wird ein Client fUr ein verbindungslose Dienste 
bereitstellendes Kommunikationsnetz implementiert, dereine Einrichtung zum Obermitteln von Verfiigbarkeitsanfragen, 
eine Einrichtung zur Oberwachung des Empfangs von Bestatigungsmeldungen, eine Einrichtung zur Obermlttlung von 
Meidungen iiberdia VerfOgbarkeitvonServern an weitere Clients sowie eine EinrichtungzurUberwachungdes Empfangs 
von Meldungen weiterer Clients und zum Unterbinden des Obermittelns von Verfiigbarkeitsanfragen aufweist. 
[0028] Die nachfolgenden Betrachtungen dienen einer Herieitung der Vorteile des beschriebenen Verfahrens zur 
Uberprufung der Verfiigbarkeit eines Servers gegenOber bisher gangigen Keep-Alive-Tests. Entsprechend den blsher 
gangigen Keep-Alive-Tests wurde ein Server bei n=:1000 VerfOgbarkeitsanfragen sendenden Clients und einer Antra- 
gerate von a=3 Anfragen pro Minute und Client sowie unter der Annahme einer zeitlichen Glelchverteilung derartiger 
Anfragen alle 

tJa = 3,» = 1000) = — = = 20ms 

a-n 3-1000 

eine Verfugbarkeitsanfrage zu beantworten haben. 

[0029] Der Server ware also durchschnittlich alle 20 ms damlt beschaftigt, eine Verfugbarkeitsanfrage zeitnah zu 
beantworten. Dies wurde zu einer erheblichen Balastung des Servers durch Verfiigbarkeitsanfragen fOhren, was ihn In 
derWahrnehmung seiner ihm eigentlich zugedachten Aufgaben stark einschranken wurde. Zur Losung dieses Problems 
wiirde sich zunachst anbieten, die Anfragerate der Clients pro Minute stark zu reduzieren, was jedoch zur Folge hatte, 
da(3 die betroffenen Clients den Verlust der Verfiigbarkeit des Server unter Umstanden unzureichend spat feststellen. 
[0030] Fur eine Abschatzung einer mit dem hler vorgeschlagenen Verfahren erzielbaren Vorteile wird zunachst an- 
genommen, dal3 sich n Clients auf s Teilnetze verteilen. Ferner wird angenommen, da(3 aus jedem dieser s Teilnetze 
wenjgstens ein Client versuchen wird, die Verfiigbarkeit des Servers abzufragen, Jeder dieser Clienst wiirde dann 
wiederum die iibrigen Clients innerhalb seines Teiinetzes mittels einer Multioast-Meidung uber die Serververfilgbarkeit 
informieren. Unter ideallsierten Bedingungen wiirde die Anzahi der durch den Server zu bearbeitenden VerfOgbarkeits- 
anfragen der Anzahl s der Teilnetze entsprechen. Zusatziich 1st noch zu beruckslchtigen, daB die Multicast-Meidungen 
in den Teilnetzen eine Verlustrate v zwlschen 0 und 1 00 Prozent aufweisen konnen. Damit ist die Anzahl v c von Clients 
pro Teilnetz, die von einer Multicast-Meldung nicht erreicht werden undsomitselber eine VerfOgbarkeitsanfrage an den 
Server senden abhangig von der Verlustrate v der Multicast-Meidungen: 



[0031] Die Gesamtzah! v c a " aller Clients, die unter dieser Voraussetzung tatsachiich eine Verfugbarkeitsanfrage an 
den Server richten laBt sich damit wie folgt abschatzen: 
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= 5-V-( l) + S = V-n-V-S+S = V*tt + s(l-v) . 



[0032] Unter diesen Annahmen kann das Zeitinterval! t r zwischsn zwet an den Server geriohteten Verfugbarkeltsan- 
fragen wie foigt berechnet werden: 



t r (a,«,s,v) = 



60j 



a-(v-n + s(l -v)) 



[0033] Anhand elnes Zahlenbeispiels wird die Belastung des Servers durch VerfQgbarkeitsanfragen bei bisher gan- 
gigen Keep-Aiive-Tests der Belastung das Servers entsprechend dem hier vorgeschlagenen Verfahrens gegenijber 
gesteSlt. Bei einer Anfragerate von a=3 VerfQgbarkeitsanfragen pro Minute und n=1000 Clients gilt fur das Zeitintervall 
t r zwischen zwei VerfQgbarkeitsanfragen: 



/ r (o-3,« = 1000,^v)- 



60s 



20s 



3-(vl000 + .y{l-v)) 1000-v + i'(i-v) ' 



[0034] TypischeWertefOr die Veriustratevliegendeutiich unter 1 00 Prozent. Mit den oblgenWertenfOr die Anfragerate 
a, die Anzahl n der Clients und s=10 Teiinetzen ergeben sich in Abhanglgkelt von der Verlustrate v die folgenden 
Effizienzsteigerungen d eff in Prozent bezogen auf die gangigen Keep-Alive-Tests mit einem Zeitintervali t r = 20 ms 
zwischen zwei VerfQgbarkeitsanfragen: 





0.0 


0.-! 


0.2 


0.5 


0,6 


t r [ms] 


2000 


183 


96 


40 


25 




9900 


815 


380 


100 


25 



[0035] Bei einer Verlustrate v = 20 % betragt die mittlere Zeit t, zwischen zwei durch den Server zu bcarbeitende 
VerfQgbarkeitsanfragen beispieisweise ca. 96 ms. Dies entsprioht einer Effizienzsteigerung d eff = 380 % im Vergieich 
zu bisher gangigen Keep-Aiive-Tests. 

[0036] Insgesamt 1st festzustellen, daR bei dem hier vorgeschlagenen Verfahren zur UberprQfung der SerververfOg- 
barkeit die Belastung das Servers durch eine Beantwortung von VerfQgbarkeitsanfragen deutlich sinkt, ohne da!3 dies 
zu einer signifikanten Erhohung derZeitfGhrt, bis den Clients die Nichtverfugbarkeit des Servers bekannt wird. AuRerdem 
sind zur Impiementierung des hier vorgeschlagenen Verfahrens lediglich auf Seiten der Clients Anderungen notwendig. 
Die bisherige VorgehensweSse zur Bearbeitung von VerfQgbarkeitsanfragen kann auf Serverseite belbehalten werden 
und erfordert damlt kelne weiteren Aufwendungen. 

[0037] Bei dem in Figur 3 dargestellten Verfahren wird zusatzlich die Verfijgbarkeit von Clients durch einen Server 
QberprOft. Dies bedeutet, dafl eln Server auch Qber die Verfijgbarkeit von Clients informiert 1st, die lediglich von einen 
anderen Client per Multicast-Meldung Qber die Verfugbarkeit des Servers Informiert werden und nicht selber Keep-Allve- 
Anfragen direkt an den Server richten. Zunachst startet Jeder Client einen erster Timer (Timer 1) (Schritt 301) und 
Qberpruft, ob eine Multicast-Sammelanfrage empfangen wurde (Schritt 302). Eine Multicast-Sammeianfrage kann von 
einem Client alsZeiohen dafdrausgesendet werden, daRdieser Client einen Sammel-Keep-A!ive-Test mit einem Server 
durchfuhren mochte, und dal3 dieser Client dafur die Keep-Alive-Daten anderer Clients benotigt. 
[0038] Der Zustand des ersten Timers wird fortlaufend durch den jewelllgen Client OberprQft {Schritt 303). Soilte der 
erste Timer noch ntcht abgelaufen und keine Multicast-Sammelanfrage eingegangen sein, so wird der Empfang einer 
Multicast-Sammelanfrage weiter uberwacht. 1st der erste Timer abgelaufen und keine Multicast-Sammelanfrage emp- 
fangen worden, so Qbernimmt der jeweilige Client die Aufgabe, selber eine Multicast-Sammelanfrage an einen ausge- 
wahlten Server zu richten. Dazu startet der jeweiiige anfragende Client einen zweiten Timer {Timer 2) (Schritt 304) und 
Qbermitfelt eine Multicast-Sammelanfrage an vorgebbare weitere Clients (Schritt 305). Nachfolgend Oberpruft der je- 
weilige anfragende Client, ob die Multicast-Sammelanfrage von den vorgebbaren weiteren Clients beantwortet wurde 
(Schritt 306}, und ob der zwaite Timer abgelaufen 1st (Schritt 307). Soilte der zweite Timer noch nlcht abgelaufen und 
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keine Antwort auf die Muiticast-Sammelanfrage eingegangen sein, so wird der Empfang einer Antwort auf die Muiticast- 
Sammelanfrage waiter iiberwacht. 

[0039] Nach Ablauf des zweiten Timers startet der jeweilige anfragende Client einen dritten Timer (Timer 3) (Schritt 
308) und sendet eine Sammel-Verfugbarkeitsanfrage an den ausgewahlten Server (Schrit! 309). Die Sammel-Verfug- 
barkeltsanfrage umfaBt Daten des jewelligen anfragenden Clients und derjenigen vorgebbaren weiteren Clients, die bis 
zum Ablauf des zweiten Timers auf die Muiticast-Sammelanfrage des jeweiligenanfragenden Clients geantwortet haben. 
Naohfolgend uberpruft derjeweilige anfragende Client, ob der ausgewahlte Server Verfijgbarkeit signalisiert hat (Schritt 
31 0), und ob der dritte Timer abgeiaufen ist (Schritt 311), Sollte der dritte Timer noch nlcht abgelaufen und keine Antwort 
auf die Sammei-VerFCigbarkeitsanfrage eingegangen sein, so wird der Empfang einer Antwort auf die Sammel-Verfiig- 
barkeitsanfrage weiter Ciberwacht. 

[0040] Hat der ausgewahlte Server seine Verfijgbarkeit dem jeweiiigen anfragenden Client signalisiert, so ijbermittelt 
der jeweilige anfragende Client eine positive Multicast-VerfGgbarkeltsmeldung an die vorgebbaren weiteren Clients 
{Schritt 312). Sollte der ausgewahlte Server seine Nlchtverfijgbarkeit signalisiert oder bis zum Ablauf des dritten Timers 
keine Antwort auf die Sammei-Verfugbarkeitsanfrage gesendet haben, so ubermittelt derjeweilige anfragende Client 
eine negative Multicast-Verfiigbarkeitsmeidung an die vorgebbaren weiteren Ciients {Schritt 313). 
[0041] Vorgebbare weitere Clients, die entsprechend der Uberpriifung in Schritt 302 eine Muiticast-Sammelanfrage 
empfangen haben, Obermitteln ihre Keep-Alive- Daten an den jeweiiigen anfragenden Client {Schritt 31 4), deren Empfang 
der jeweilige anfragende Client entsprechend Schritt 306 uberpruft. Nachfolgend starten die vorgebbaren weiteren 
Clients einen vierten Timer (Timer 4) (Schritt 315) und Oberpriifen, ob eine positive oder negative Muiticast-Verfugbar- 
keitsmeldung des Jeweiiigen anfragenden Clients empfangen wurde (Schritt 316), und ob der vierte Timer abgelaufen 
ist (Schritt 31 7). Bei Empfang einer Multicast-VerfGgbarkeitsmeidung des jeweiiigen anfragenden Clients wird der erste 
Timer zurilckgesetzt (Schritt 31 8), so daR die vorgebbaren weiteren Clients fur eine durch den Ablauf des ersten Timers 
bestimmte Zeitdauer keine VerfQgbarakeltsanfragen an den ausgewahlten Server richten. 

[0042] Solange der vierte Timer nicht abgelaufen ist, warten die vorgebbaren weiteren Clients auf eine Multicast- 
Verfugbarkeltsmeldung des jeweiiigen anfragenden Clients. Sollte dies nicht vor Ablauf des vierten Timers geschehen, 
Obernimmt derjeweilige Client nun seibst eine Rolls ais SteSier einer Sammei-VerfOgbarkeltsanfrage entsprechend den 
Schritten 304 bis 313, sofern der erste Timer abgelaufen ist bzw. vor seinem Ablauf keine weitere Muiticast-Sammel- 
anfrage cingeht. 

[0043] DieAnwendungdervorliegendenErfindungistnichtaufdashlerbeschrlebeneAusfuhrun3i-i^i r ^ ! « c rank: 



Patents nsprtiche 

1. Verfahren zur Uberpriifung der Verfijgbarkeit eines Servers (102, 103, 104), bei dem 

- eine Verfugbarkeitsanfrage von einem Client (111-115, 121-123, 131-133) an einen Server ubermittelt wird, 

- die Verfugbarkeitsanfrage bei Verfijgbarkeit des Servers durch eine vom Server an den Client ijbermittelte 
Bestatigungsmeldung beantwortet wird, 

cfadurch gekennzeichnet, dafl der Client eine Meldung Ober die Verfijgbarkeit des Servers an weitere Clients 
ubermittelt, die daraufhin jeweils eln Obermitteln einer Verfugbarkeitsanfrage an den Server zumindest fur eln 
vorgebbares Zeitintervall unterblnden. 

2. Verfahren nach Anspruch 1 , 

dadurch gekennzeichnet, daB Daten zwischen dem Server und den Ciients mitteis verbindungsloser Vermitt- 
lungssteuerung ubermittelt werden. 

3. Verfahren nach einem der Ansprilche 1 oder 2, 

dadurch gekennzeichnet, daB die Meldung iiber die Verfijgbarkeit des Servers an die vorgebbaren weiteren 
Clients mitteis Multicast ubermittelt wird. 

4. Verfahren nach einem der Ansprilche 1 bis 3, 

dadurch gekennzeichnet, daB der Client nur vorgebbare weitere Clients innerhalb desseben Teilnetzes Ober die 
Verfugbarkelt des Servers informiert. 

5. Verfahren nach einem der Ansprilche 1 bis 4, 

dadurch gekennzeichnet, daB der Client zu durch eine Zeitsteuerung vorgegebenen Zeitpunkten Verfugbarkeits- 
anfragen ausfilhrt. 
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6. Verfahren nach Anspruch 5, 

dadurch gekennzeichnet, daB jewsils ein Zahler einer Zeitsteuerung, die sinem vorgebbaren weiteren Client 
zugeordnetistundVerfagbarkeitsanfragenvsranlaBt,beiEmpfangeinerMeldung(iberdie Verfugbarkeit des Servers 
auf einen vorgebbaren Wert zurUckgesetzt wird. 

7. Steuerungsprogramm, das In elnen Arbeitsspeicher eines Clients (111-115, 121-123, 131-133) iadbarist und zu- 
mindest einen Codeabschnitt aufweist, bei dessen Ausfuhrung 

- eine Verfugbarkeitsanfrage von dem Client an einen Server (102, 103, 104) ubermittelt wird, 

- ein Empfang einer die Verfugbarkeitsanfrage bei Verfugbarkeit des Servers beantwortendon Bestatigungs- 
meldung uberwacht wird, 

- eine Meldung iiber die Verfugbarkeit des Servers an weitere Clients Ubermittelt wird, 

- ein Empfang einer Meldung eines vorgebbaren weiteren Clients Uber die Verfugbarkeit des Servers Uberwacht 
und ein Obermitteln einer Verfugbarkeitsanfrage an den Server zumindest fur ein vorgebbares Zeitintervall bei 
Empfang einer solchen Meldung unterbunden wird, 

wenn das Steuerungsprogramm in dem Client ablauft. 

8. Client (1 1 1-115, 121-123, 131-133) fur ein verbindun-gslose Dienste bereitstellendes Kommunikationsnetz m'rt 

- einer Einrichtung zum Obermitteln einer Verfugbarkeitsanfrage an einen Server (1 02, 103, 104), 

- einer Einrichtung zur Oberwachung eines Empfangs einer die Verfugbarkeitsanfrage bei Verfugbarkeit des 
Servers beantwortenden Bestatigungsmeldung, 

- einer Einrichtung zur Obermittlung einer Meldung Qber die Verfugbarkeit des Servers an weitere Clients, 

- einer Einrichtung zur Oberwachung eines Empfangs einer Meldung eines vorgebbaren weiteren Clients iiber 
die Verfugbarkeit des Servers und zum Unterbinden eines Ubermittelns einer VerfOgbarkeitsanfrage an den 
Server zumindest fur ein vorgebbares Zeitintervall bei Empfang einer sofchen Meldung. 



1. Method for checking the availability of a server (102, 103, 104), in which 

-an availability request is transmitted from a client (11 1-1 15, 121-123, 131-133) to a server, 

- the availability request is answered by a confirmation message transmitted from the server to the client if the 

server is available, 

characterized in that the client transmits a message about the availability of the server to further clients which then 
respectively prevent transmission of an availability request to the server at least for a prescribable time interval. 

2. Method according to Claim 1 , 

characterized i n that data are transmitted between the server and the clients by me ans of con n ectio n less s witchi ng 
control. 

3. Method according to one of Claims 1 and 2, 

characterized in that the message about the availability of the server is transmitted to the prescribable further 
clients by means of multicast. 

4. Method according to one of Claims 1 to 3, 

characterized in that the client informs only prescribable further clients within the same subnetwork about the 
availability of the server. 

5. Method according to one of Claims 1 to 4, 

characterized in that the client makes availability requests at times prescribed by a time controller. 

6. Method according to Claim 5, 

characterized in that a respective counter in a time controller which is associated with a prescribable further client 
and prompts availability requests is reset to a prescribable value upon reception of a message about the availability 
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of the server. 

7. Control program which can be loaded into a main memory in a client (1 11-1 15, 121-123, 131 -133) and has at least 
one code section, which, when executed, prompts 

- an availability request to be transmitted from the client to a server (102, 1 03, 1 04), 

- reception of a confirmation message answering the availability request when the server Is available to be 
monitored, 

- a message about the availability of the server to be transmitted to further clients, 

- reception of a message from a prescribable further client about the availability of the server to be monitored, 
and transmission of an availability request to the server to be prevented at least for a prescribable time interval 
upon reception of such a message, 

when the control program is executed in the client. 

8. Client (11 1-115, 121-123, 131-133) for a communication network providing connectionless services, having 

-a device tor transmitting an availability request to aserver(102, 103, 104), 

- adevice formonitoring reception of a confirmation message answeringthe availability request when the server 
Is avaiiable, 

- a device for transmitting a message about the availability of the server to further clients, 

- a device for monitoring reception of a message from a prescribable further client about the availability of the 
server and for preventing transmission of an availability request to the server at least for a prescribable time 
interval upon reception of such a message. 



Revendications 

1. Precede de controle de la disponlbilite d'un serveur ( 102, 103, 104 ) dans lequel 

ontransmet une interrogation de disponibilite d'un client < 1 1 1 a 115, 121 a 123, 131 a 133 ) a un serveur, 

II est repondu a la question do la disponibilite si le serveur est disponible par un message de confirmation transmis 

du serveur au client, 

caracterise en ce que le client transmet un message sur la disponlbilite du serveur a d'autres clients qui, ensulte, 
suppriment, au molns pendant un intervalle de temps pouvant etre prescrit, une transmission d'une interrogation 
de disponlbilite au serveur. 

2. Procede suivant la revendlcation 1, 

caracterise en ce que Ton transmet des donnees entre le serveur et le client au moyen d'une commande de 
transmission sans fil, 

3. Procede suivant I'une des revendications 1 ou 2, 

caracterise en ce que Ton transmet le message sur la disponlbilite du serveur aux autres clients pouvant etre 
prescrlts au moyen de Multicast. 

4. Procede suivant i'une des revendications 1 a 3, 

caracterise en ce que le client n'infomne de la disponibilite du serveur que d'autres clients pouvant etre presents 
au sesn du meme sous-reseau. 

5. Procede suivant i'une des revendications 1 a 4, 

caracterise en ceque le client execute des interrogations de disponlbilite a des instants presents par une commande 
temporelle. 

6. Procede suivant la revendlcation 5, 

caracterise en ce que, respectlvement, un compteur de commande temporelle, qui est associe a un autre client 
qui peutetre prescrit et qui provoque des interrogations de disponlbilite, est remis a une valeur pouvant etre presents 
a reception d'un message sur la disponibilite du serveur. 



7. Programme de commande, qui peut etre charge dans une memoire de travail d'un client {111 a 1 15, 121 a 123, 
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1 31 a 1 33 ) et qui a au moins une section de code, dans ia realisation duquel 

une interrogation de disponibilite est transmise du cSlent a un serveur ( 1 02, 1 03, 1 04 ), 

une reception d'un message de confirmation repondant a I'interrogation de disponibilite lorsque le serveur est 

disponible est surveiilee, 

un message sur 5a disponibilite du serveur est transmis a d'autres ciients, 

une reception d'un message d'un autre client pouvant etre present sur la disponibilite du serveur est surveiilee et 
une transmission d'une interrogation de disponibilite au serveur est supprimee, au moins pendant un intervaile de 
temps pouvant etre prescrit, a reception d'un message de ce genre, 
lorsque le programme de commands se deroule chez le client. 

Client ( 111 a 115, 121 a 123, 131 a 133) pour un reseau de communications mettant a disposition des services 
sans fil comprenant 

un dlspositlf de transmission d'une interrogation de disponibilite a un serveur ( 1 02, 1 03, 1 04 ), 

un dispositif de surveiilance d'une reception d'un message de confirmation repondant a I'interrogation de disponibilite 

lorsque le serveur est disponible, 

un dispositif de transmission d'un message sur la disponibilite du serveur a d'autres clients, 
un dispositif de surveillance d'une reception d'un message d'un autre client pouvant etre prescrit sur la disponibilite 
du serveur et de suppression d'une transmission d'une interrogation de disponibilite au serveur, au moins pendant 
un intervaile de temps pouvant etre prescrit, a reception d'un message de ce genre. 
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